[イベントレポート] サポーターズ勉強会 アプリが動いたその先へ(iOS アプリ開発編) に参加してきました!
はじめに
おばんです、個人開発で久々にiOSに触れたら、UITextFieldのリターンイベント検知だけで興奮してしまった田中です。イベントトンデクルーーー!タノシーーー!!!
さて本題です。今回のエントリは サポーターズ勉強会 アプリが動いたその先へ(iOS アプリ開発編) のイベントレポートになります。講師は LINE 株式会社で iOS アプリエンジニアをなさっている、繪面 友香さんです。
イベント概要
iOS アプリ開発を始めたころ、ネットや本のサンプルコードを真似しつつ、
試行錯誤しながらアプリを作っていました。
楽しいながらも、当時、多くの苦悩がありました。
おまじないのように書くコードの意味はなんなのか、 本当にこの書き方は正しいのだろうか、 重大な間違いをしていないだろうか、 自分のコードは、設計は、一般的に良いのか、 とりあえず動くけど、不安だ…
もし、少しでも似た悩みを持つ人がいたら、 7年経った今、伝えたいこと、伝えられることがたくさんあります。
サポーターズCoLabより引用
内容
今日の話の流れ
- 誰だって最初は初心者
- コードを写経したりコピペしたら、よくわからないけどとりあえずアプリができた(retain, delegate, ...)
- なんかメモリリークしてたけどアプリができていた(砂のお城のようなコード)
- プロとして恥ずかしくないアプリを作りたい
- そうこうしているうちに初心者だった時に疑問だったこと、悩んだことに答えるようになってきた
- 今日はそんな疑問、アプリが組めるようになって、その先さらに一歩に進むための話をします
- 答えを出すには
- 原則・原理(基礎) → 状況 → 答えの順に導き出される
- 原則・原理(基礎)をしっかりと抑えておけば、変化する状況に対応できるようになり、答えが導き出せるようになる
- キホン大事。なので、おさらいしていきましょう
目次、取り扱う技術的内容
- 参照・メモリ周り
- thread
参照・メモリ周り
- strong/weakってなんで必要なの?
- オブジェクトを保持するときはメモリ領域を確保する
- オブジェクトを保持し続けると、メモリが足りなくなる。要らなくなったらメモリは解放しなくてはいけない。いつ開放すればいいのか?
- オブジェクトが「要らない」ときってどういうとき?
- メモリ管理の仕方は言語によって様々
- Java, Ruby, JavaScript, ...
- Garbage Collection
- Swift, Objective-C
- Reference Counting
- Java, Ruby, JavaScript, ...
- メモリ管理の仕方は言語によって様々
- Reference Counting
- Swift, Objective-CはARC(Automatic Reference Counting)を利用している
- weak参照とstrong参照のある世界
- 循環参照
- weak/strongの使い分けは状況による。設計の段階で、親子関係をよく考えよう
- クロージャにおけるweak/strongの管理も、場合によってはstrongのままでも良い場合があるのでそこもよく考えよう
- Q.) xibから生成するviewはweakであるべきか?strongであるべきか?
- A.) わりとどちらでもよい。通説ではweakのほうがよい。
- VCに保持するview要素はVC.viewにaddSubviewされるため、、VC.viewが破棄されればそのsubviewは破棄されるようになっているのでどちら大丈夫
- ただし、memoryWarningなどでVC.viewを破棄して生成し直すなどの処理をするような場合があれば、view要素をweakで保持した方が良い
thread
- main thread(アプリに1つだけ)
- UIの操作はmain threadで行おう
- main thread以外で行うとどうなるのか?
- main threadではRun loop(無限ループ)がまわっている
- Run loopの中で(タップ)イベントがこないかどうか待ち構えている
- イベントが来たら、viewに通知する
- もし重い処理(通信、DB操作など)をmain threadで行ったら...?
- タップ操作などが受け付けられなくなる
- 画面がロックされるなどが怒る
threadにまつわる問題集
問1) 以下のコードでlabelのtextColorとviewのbackgroundColorが切り替わるのはどういう順序でしょうか?
- A1) label.textColorの更新発火 -> 2秒待つ -> labelとview.backgroundColorの更新
- 解説) viewの実際の更新処理は様々な再計算が行われるため、発火したからといってすぐさま反映されるわけではない。その前にsleepの命令が実行されるので、更新はその後となる
問2) 以下のコードでlabelのテキストカラーが更新されるタイミングはいつでしょうか?
- A2) いつかわからない
- 解説) viewの更新操作はサイズなどの様々なプロパティを再計算するため、再描画されるまでに時間がかかる。バックグランドで行われたUI更新処理はそれが反映されるタイミングが保証されていないため、即時に切り替わることがない(予想)
問3) NotificationCenterが実行されるthreadはどこのthreadでしょうか?
- A3) notificationを発行したthreadで呼ばれる
Q&A
- Q) ZombieObjectってどういうものでしたでしょうか。
- A) 以下のコードのようなもの。 lazy var で宣言したプロパティにnilをセットすると呼び出し順序の問題で、再度initializeされてしまうものがZombieObject。Swift 4で改善された気がしています。
まとめ
メモリ管理とthread制御は初心者から一歩進んだ開発を行う際に避けて通れない、理解の難しい部分だったと記憶しています。そういった概念の説明が丁寧にされたとても良い会でした!
個人的にも曖昧だったところが整理されて、得るものがありました。講師の繪面さん、ありがとうございました!